本系列所有程式碼都由 AI 撰寫，我負責決定要做什麼、確認結果。
今天先把 Vibe Coding 的工作環境準備好。

1. 實際上，我只做了五個步驟

1. 建立一個空資料夾 ObsidianTrial
2. 用 VSCode 開啟這個資料夾
3. 在 VS Code 裡安裝延伸模組 Claude Code for VS Code
4. 打開 Claude Code，跟它說：「幫我安裝 Godot」 
5. 把遊戲的架構寫進 README.md

沒了，就這五個步驟。

在 Vibe Coding 的方式下，安裝開發工具也不一定要自己一步一步處理。
這次我先在 VS Code 裡安裝 Claude Code。安裝完成後，Claude Code 就可以直接從 VS Code 裡進入我的專案。
接著我在 Claude Code 裡輸入：

幫我安裝 Godot

Claude Code 先判斷我的電腦是 macOS，接著選擇使用 Homebrew 安裝，執行相關指令，再確認 Godot 是否安裝成功。

我的工作主要就是在 AI 要執行動作時按下「允許」。

安裝完成後，它也會繼續確認版本和相關路徑。

先說一下 Claude Code

這裡先說明一下，因為後面會一直提到 Claude 和 Claude Code。

瀏覽器裡的 Claude 主要用來聊天、討論問題；Claude Code 則可以直接進入專案，讀取和修改檔案，也能執行終端機指令。

所以本系列後面提到「叫 AI 動手做」，指的都是 Claude Code。
這次安裝 Godot 時，我直接告訴 Claude Code：

幫我安裝 Godot

它會根據我的電腦環境選擇適合的方式執行，我再確認最後的結果。
例如執行：

godot --version

結果是：

4.7.1.stable.official.a13da4feb

我這次安裝的是 Godot 4.7.1，後面的內容都以 Godot 4.x 為基礎。

也可以在 VS Code 用命令列打開 godot

% godot -e

這樣 Godot 編輯器就會直接打開。

一個容易被忽略的順序

一般看到的 Godot 教學，大多是：

安裝 Godot → 開啟 Project Manager → 建立新專案

但我這次的順序是：

建立資料夾 → 用 VS Code 開啟 → 安裝 Godot

這是因為這次的開發方式，是以 VS Code + Claude Code 為主要工作環境。
我先建立專案資料夾，讓 Claude Code 進入這個專案，再由它幫我安裝 Godot。

Godot 編輯器則主要用來查看遊戲畫面、節點和屬性。實際的檔案建立、修改和許多操作，會由 Claude Code 在 VS Code 裡完成。

所以對我來說，Godot 比較像是這個專案裡的一個開發工具，和 Git 有點類似。這些工具的安裝，也可以交給 AI 處理。

至於為什麼這次選 Godot，而不是 Unity 或 Unreal，我放在附錄 1 說明。

2. 這次花多少錢？

Claude Code 需要付費方案。
我使用的是 Claude Pro ，目前大約 NT$600 多元一個月，實際價格還是以官網為準。

這次實驗目前使用了大約兩個月。以我平常的開發量來說，沒有很常遇到額度用完的情況。
換算下來，一天大約 20 元左右。
對我來說，這筆錢比較像是開發工具的投資。

因為聊天型 AI 和 Coding Agent 的工作方式差很多。
以前用聊天型 AI 寫程式時，通常是：

AI 寫程式 → 我複製程式 → 貼到專案裡 → 執行 → 出錯 → 把錯誤再貼回 AI

程式一多，這種來回就會變得很麻煩。

更重要的是，聊天型 AI 通常只知道我貼給它的內容。它看不到整個專案，也不會自動知道其他檔案之間的關係。

例如這個專案裡，我會有一份 CLAUDE.md，裡面放著專案的開發規則和一些需要長期記住的資訊。這類檔案可以讓 Claude Code 每次進入專案時，都先知道這個專案有哪些規則。

Claude Code 則可以直接進入我的專案，查看檔案、了解目前的程式結構，讀取 CLAUDE.md，再直接修改程式和執行指令。

所以我付費使用的，是讓 AI 可以直接在我的專案裡工作。

這也是為什麼我在真正進入開發階段後，開始把這筆費用當成開發工具的投資。

前面的 Day 01～Day 03，主要都是規劃和討論，我使用 Gemini 的免費方案就可以完成。

這次我的做法是：

• 前期規劃： Gemini 免費方案
• 進入專案開發： Claude Code 付費方案

這樣可以把付費的成本集中在真正需要它的地方。

如果你現在還沒開始寫程式，也不用急著先訂閱。等到準備讓 AI 直接進入專案工作時，再決定要不要投入這筆費用。

Day 02 已經談過為什麼我會把「討論」和「施工」分開，這裡就不再重複。

3. AI 做什麼？我做什麼？

環境搭好之後，我開始想另一個問題：

既然 AI 已經可以直接進入專案工作，那我自己還要做什麼？

這次我的分工大概是這樣：

AI 可以幫我把東西做出來，也可以解釋我看不懂的地方；最後要做什麼、想學什麼，還是由我決定。

這次實驗裡，我比較像製作人和驗收的人，AI 則負責大量的工程工作。
而且 AI 不會因為我一直修改需求就累了。

4. 我後來發現，一個很好用的功能是「讓 AI 自己驗證」

一般使用 AI 寫程式，很容易變成這樣：

AI 寫程式 → 我複製貼上 → 執行 → 出錯 → 把錯誤訊息貼回 AI → AI 修正

如果讓 Claude Code 直接在專案裡工作，就可以變成：

AI 寫程式 → AI 自己執行檢查 → 發現錯誤 → AI 自己修正 → 把結果交給我

這樣可以少一次來回，也能減少一些不必要的 AI 使用量。
例如，我會讓 Godot 直接檢查 GDScript：

godot --headless --script scripts/CardDatabase.gd --check-only

如果有問題，它會直接告訴我：

• 哪一個檔案
• 哪一行
• 錯誤原因

這樣我就不需要每次都自己執行、找錯誤，再把錯誤貼回 AI。
不過這裡也有一個坑：

有時候看起來檢查成功了，實際上程式裡還是有錯。

所以不能只看「指令有沒有跑完」，還要確認檢查結果是不是真的正確。
這個問題後面真的踩到了，Day 09 再來講。

5. 今天的環境，先到這裡

今天主要完成了四件事：

1. 建立專案資料夾
2. 用 VS Code + Claude Code 作為主要工作環境
3. 安裝並確認 Godot
4. 讓 AI 可以自己執行部分檢查

接下來，專案裡還會慢慢建立幾份不同用途的文件。

例如 README.md 可以記錄遊戲的玩法、卡牌設計、數值和專案結構；CLAUDE.md 則可以放給 Claude Code 看的開發規則和需要長期記住的資訊。

因為每次 AI 重新進入專案時，不一定知道我們之前討論過什麼。
這些內容如果只留在聊天紀錄裡，之後還是要重新說明。

所以 Day 05，我要開始整理其中最基本的一份：

怎麼寫一份讓 AI 一看就懂的專案規格？

也就是這個專案的 README。

附錄 1：為什麼這次選 Godot？

我前面提過，Godot、Unity、Unreal 都可以做遊戲。
這次選 Godot，除了免費、開源、比較輕量之外，對我來說還有一個很重要的原因：

Godot 的專案檔案，大多是 AI 可以直接閱讀和修改的文字。

例如 .tscn 場景檔，大概會長這樣：

[gd_scene load_steps=2 format=3]
[ext_resource type="Script" path="res://scripts/Card.gd" id="1"]
[node name="Card" type="Panel"]
offset_right = 120.0
offset_bottom = 160.0
script = ExtResource("1")

這些內容人可以看，AI 也可以直接讀取、修改，甚至產生。

簡單比較：

對這次「讓 AI 直接進入專案施工」的實驗來說，這個差異很重要。

另外，我這次做的是 2D Roguelike 卡牌遊戲，並不需要很複雜的 3D 功能。
Godot 本身就能勝任這類 2D 遊戲，所以對這次實驗來說已經足夠。

這也是我最後選擇 Godot 的原因之一：遊戲類型符合，加上專案檔案容易讓 AI 直接讀取和修改。